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TITLE OF THE INVENTION 
PURCHASE REQUEST APPROVING ^PPARATUS AND PURCHASE REQUEST 

APPROWNG METHOD 



5 BACKGROUND OF THE INVENTION 

The present invention relates to a purchase request 

approving apparatus and purchase request approving method 

for requesting purchase of articles. 
10 Conventionally, companies and business offices 

purchase various articles necessary for daily business 

operations from external suppliers. 

There are a variety of articles to be purchased. 

However, for example, purchases of articles such as 
15 stationery, for which purchase requests are issued in units 

of sections, are generally made according to the following 

procedure and get behind in office automation and paperless 

transactions . 

A general clerk or the like issues a purchase slip 
20 for specif ying a desired article . Next, a manager approves 

the issued slip by, e.g., sealing (signature). The 

approved slip is handed over to the procurement department . 

The procurement department puts a plurality of orders into 

a lot as needed, newly issues a purchase order slip, and 
25 sends it to an external supplier. With this procedure, the 

desired articles are delivered. 
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SUMMARY OF THE INVENTION 
It is an object of the present invention to provide 
a purchase request approving apparatus and purchase request 
5 approving method capable of abolishing the conventional 
business procedures including preparation, issue, and 
transfer of physical purchase slips and efficiently 
inputting approval or rejection of a purchase-requested 
article . 

10 In order to achieve the above object, a purchase 

request approving apparatus according to the present 
invention has the following arrangement. 

There is provided a purchase request approving 
apparatus capable of approving a purchase request of a 

15 desired article, characterized by comprising display means 
for displaying information, which is stored in a database 
in advance, associated with articles for which approval of 
purchase is requested, and purchase approving means capable 
of storing, in the database, information representing 

20 approval or rejection of purchase of an article selected 
from the articles displayed by the display means. 

The apparatus is characterized in that a requester 
capable of purchase request for the desired article belongs 
to a group based on predetermined common information, and 

25 the apparatus further comprises requester group setting 
means capable of setting a desired requester group 
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different from the group of requesters for which approval 
or rejection of purchase is to be determined by the purchase 
approving means in accordance with the predetermined common 
information . 

5 The apparatus is characterized in that the group of 

requesters is a section group in a company, and the 
predetermined common information is an identification code 
representing each section of the company. 

The apparatus is characterized in that the display 
10 means is a browser of an internet, which is executed by the 
purchase request approving apparatus connected to a 
communication network, and the purchase approving means is 
constructed by a predetermined Web page displayed by the 
browser . 

15 

Further, the foregoing object is attained by 
providing a purchase request approving method of approving 
a purchase request of a desired article using a computer, 
characterized by comprising a display step of displaying 

20 information, which is stored in a database in advance, 
associated with articles for which approval of purchase is 
requested and a purchase approving step of storing, in the 
database, information representing approval or rejection 
of purchase of an article selected from the articles 

25 displayed in the display step. 
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Other features and advantages of the present invention 
will be apparent from the following description taken in 
conjunction with the accompanying drawings, in which like 
reference characters designate the same or similar parts 
5 throughout the figures thereof. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a view showing the overall arrangement of 
a purchase request system according to an embodiment of the 
10 present invention; 

Fig . 2 is a block diagram of a personal computer which 
can be used as a client computer in the embodiment of the 
present invention ; 

Fig. 3 is a view showing the system configuration of 
15 software executed by the A/S of the purchase request system 
according to the embodiment of the present invention; 

Fig. 4 is a view showing the system configuration of 
software executed by the A/S of the purchase request system 
according to the embodiment of the present invention; 
20 Fig. 5 is a view showing the system configuration of 

software executed by the A/S of the purchase request system 
according to the embodiment of the present invention; 

Fig. 6 is a view for explaining symbols used in 
Figs. 3 to 5; 

25 Fig. 7 is a view showing a mailer window displayed 

when approval request mail is sent to the approver by the 
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mailer function of the purchase request system according 
to the embodiment of the present invention; 

Fig. 8 is a view showing a mailer window displayed 
when mail replying to the approval request is sent to the 
5 requester by the mailer function of the purchase request 
system according to the embodiment of the present 
invention; 

Fig . 9 is a view showing a login window in the purchase 
request system according to the embodiment of the present 
10 invention; 

Fig. 10 is a view showing a user information 
registration/change window in the purchase request system 
according to the embodiment of the present invention; 

Fig. 11 is a view showing a request state display 
15 window in the purchase request system according to the 
embodiment of the present invention; 

Fig. 12 is a view showing the dialogue box for 
designating search conditions and display form in the 
request state display window; 
20 Fig. 13 is a view showing icon images indicating the 

number of purchase-requested articles in the embodiment of 
the present invention; 

Fig. 14 is a view showing the catalog search window 
of the purchase request processing function of the purchase 
2 5 request system according to the embodiment of the present 
invention ; 



- 5 - 



Fig. 15 is a view showing the catalog list window of 
the purchase request processing function of the purchase 
request system according to the embodiment of the present 
invention; 

5 Fig. 16 is a view showing the individual input window 

of the purchase request processing function of the purchase 
request system according to the embodiment of the present 
invention; 

Fig. 17 is a view showing the requested article 
10 selection list window of the purchase request processing 
function of the purchase request system according to the 
embodiment of the present invention; 

Fig. 18 is a view showing the detail information 
input window for a many-item request of the purchase request 
15 processing function of the purchase request system 

according to the embodiment of the present invention; 

Fig. 19 is a view showing a state wherein the approval 
request window for a many-item request is displayed 
together with the detail information input window by the 
20 approval request processing function of the purchase 

request system according to the embodiment of the present 
invention; 

Fig . 20 is a view showing a state wherein the approval 
request window for a one-item request is displayed together 
25 with the detail information input window by the approval 
request processing function of the purchase request system 
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according to the embodiment of the present invention; 

Fig. 21 is a view showing conditions of cross-check 
executed by a client in inputting data to the detail 
information input window in the purchase request system 
5 according to the embodiment of the present invention; 

Fig. 22 is a view showing the error window displayed 
when the desired due date of delivery input in the detail 
information input window has an error in the purchase 
request system according to the embodiment of the present 
10 invention; 

Fig. 23 is a view showing the acceptance result list 
window displayed by the acceptance result display function 
in the purchase request system according to the embodiment 
of the present invention; 
15 Fig. 24 is a view showing the approval request list 

window displayed by the approval processing function in the 
purchase request system according to the embodiment of the 
present invention; 

Fig. 2 5 is a view showing the approval processing 
20 window of the approval processing function in the purchase 
request system according to the embodiment of the present 
invention; 

Fig. 26 is a view showing the rejection processing 
window of the approval processing function in the purchase 
2 5 request system according to the embodiment of the present 
invention; 
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Fig. 27 is a view showing the temporary worker list 
window of the temporary worker management function in the 
purchase request system according to the embodiment of the 
present invention ; 

Fig. 28 is a view showing the temporary worker 
registration window of the temporary worker management 
function in the purchase request system according to the 
embodiment of the present invention; 

Fig. 29 is a view showing the temporary worker 
deletion window of the temporary worker management function 
in the purchase request system according to the embodiment 
of the present invention; 

Fig. 30 is a flow chart of software executed by each 
client in the purchase request system according to the 
embodiment of the present invention; 

Fig. 31 is a flow chart showing the outline of 
processing executed by the A/S of the purchase request 
system according to the embodiment of the present 
invention ; 

Fig. 32 is a flow chart showing the outline of 
processing executed by the A/S of the purchase request 
system according to the embodiment of the present 
invention; and 

Fig. 33 is a flow chart showing window display 
processing common to modules executed by the A/S of the 
purchase request system according to the embodiment of the 



present invention . 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
An embodiment of the present invention will be 
5 described below in detail with reference to the 
accompanying drawings. 
[Hardware Configuration of System] 

The overall hardware configuration of a purchase 
request system of this embodiment will be described first. 
10 Fig. 1 is a view showing the overall arrangement of 

the purchase request system according to the embodiment of 
the present invention. 

Referring to Fig. 1, reference numeral 3 0 denotes a 
communication line as a LAN (Local Area Network) or WAN 
15 (Wide Area Network) ; 1, a plurality of client computers (to 
be referred to as clients hereinafter) ; 1A, a client for 
a system manager for maintaining and managing the system; 
and 2, an application server computer (to be referred to 
as an A/S hereinafter) for realizing a purchase request 
20 function (to be described later) and the like. 

A Web server computer (to be referred to as a W/S 
hereinafter) 3 provides a so-called intranet environment 
in accordance with general software for realizing, e.g., 
the WWW (World Wide Web) function in a client-server system 
25 constituted by the plurality of clients 1 (including the 
client 1A) and A/S 2 . A mail server computer ( to be referred 
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to as an M/S hereinafter) 4 controls/manages electronic 
mail transmission/reception between the clients in 
accordance with general mail management function (mailer) 
software. A database (D/B) 5 systematically stores 
5 various data associated with the purchase request system 
on the communication line 30. 

Personnel data 7 is used in this purchase request 
system, which is included in various personnel data stored 
by an external system (to be referred to as a personnel 

10 information management system hereinafter) for 

systematically managing the personnel information of a 
company to which the users of the clients 1 and 1A belong. 
The personnel data. 7 correlates at least the names, employee 
numbers, and positions of employees with each other in 

15 advance. The system manager for maintaining and managing 
the client 1A copies the personnel data 7 as identification 
(ID) information of users (employees) who can use the 
purchase request function (to be described later) in the 
clients 1 to a portable storage medium 8 such as a floppy 

20 disk and downloads the copy data from, e.g. , the client 1A 
to the D/B 5. 

The storage medium 8 is used to copy the personnel 
data 7 because a number of personal information of the 
employees are generally stored in the personnel information 

25 management system. As far as a sufficient security 

guarantee function can be realized between the personnel 



- 10 - 



data 7 and the purchase request system, the personnel data 
7 may be downloaded through the communication line 
periodically and/or irregularly, or the master information 
of the personnel data 7 in the personnel information 
management system may be accessed when each client 1 logs 
in to the A/S 2. 

In this purchase request system, a plurality of W/Ss 
3 are connected through a leased line and/or public line 
31. With this arrangement, the same intranet environment 
as that for the clients 1 can be provided to clients 
connected to a communication line (not shown; LAN or WAN) 
in another business office. 

Data associated with articles to be purchased, which 
is stored in the D/B 5 by the purchase request function (to 
be described later) , is appropriately updated between the 
D/B 5 and a database 6 prepared in another system used to 
actually order the articles to external suppliers. The 
database 6 is included in, e.g. , an article ordering system 
managed and used by the procurement department in the 
company (business office) . On the basis of the data of 
articles to be purchased, which is reflected to the database 
6, the article ordering system puts an article whose 
purchase quantity is large into a desired lot and actually 
orders the article to an external supplier. To actually 
order an article, the general EDI (Electronic Data 
Interchange) function is used, or an actual slip is issued 




as needed. A detailed description thereof will be omitted 
in this application. The purchase request system may 
incorporate the function of the article ordering system. 

If the company (business office) has no procurement 
5 department, and individual users who have requested to 
purchase articles can manage the article order, articles 
for which purchase is approved by approval processing (to 
be described later) may be directly ordered by the purchase 
request system. 

10 In this embodiment, the purchase request system is 

realized on the intranet shown in Fig. 1. However, the 
present invention is not limited to this. If security of 
data to be transmitted/received can be ensured, the 
communication line 3 0 may be connected to a so-called 

15 Internet provider in place of some W/Ss 3 to allow a personal 
computer at a remote site as the client 1. 

Fig. 2 is a block diagram of a personal computer which 
can be used as a client computer in the embodiment of the 
present invention. The client computer corresponds to the 

20 client 1 (1A) shown in Fig. 1. 

Referring to Fig. 2, reference numeral 22 denotes a 
display 22 such as a CRT; 23, a keyboard as an input means; 
24, a ROM which stores a boot program and the like; and 25, 
a RAM for temporarily storing various processing results. 

25 A storage unit 26 such as a hard disk drive (HDD) stores 
a general browser program that realizes access to a site 
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(information resource) of a desired URL (Uniform Resource 
Locator) and browsing and/or acquisition of information of 
the accessed site. A communication interface 27 
communicates with external apparatuses such as the 
5 above-described servers through the communication line 3 0 
(LAN or WAN) in accordance with a protocol such as the TCP/IP 
(Transmission Control Protocol/Internet Protocol) or HTTP 
(HyperText Transfer Protocol) as an upper layer of TCP/IP. 
Reference numeral 2 8 denotes a pointing device such as a 
10 mouse. These units are connected via an internal bus 29. 
A CPU 21 controls the entire client computer 1 (1A) in 
accordance with the program stored in the storage unit 26. 

For each of the server computers such as the A/S 2, 
W/Ss 3, and M/S 4 as well, the display 22, keyboard 23, and 
15 pointing device 2 8 are prepared as needed. The basic 

hardware configuration of each server is substantially the 
same as that of the block diagram in Fig. 2 . However, when 
accurate data processing by the servers and restoration of 
stored data are taken into consideration, hardware that 
20 duplicates the CPU 21 and storage unit 2 6 is employed. In 
this embodiment, separate servers are used in accordance 
with the function realized by each server. However, the 
present invention is not limited to this. As long as the 
data processing capability is sufficient, for example, the 
2 5 A/S 2 and M/S 4 may be realized by single hardware. 
[Software Configuration of System] 
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The purchase request function realized by the system 
of the above-described embodiment will be described next. 
In the following description, the user (e.g., a general 
clerk) of the client 1 for requesting to purchase an article 
5 is called a "requester", and the user (e.g. , a manager with 
a rank equal to or higher than a section manager) of the 
client 1 for determining approval or rejection of the 
purchase request for the article is called an "approver". 
The purchase request system according to this 

10 embodiment will be briefly described. This system has a 
function with which the requester specifies (selects) a 
desired article prior to actual order of the article to be 
purchased by the external article ordering system shown in 
Fig. 1, a function as a purchase request apparatus for 

15 requesting the approver to approve purchase of the 

specified article, and a function as a purchase request 
approving apparatus with which the approver determines 
approval or rejection of purchase of the approval-requested 
article in a client-server environment where a plurality 

20 of clients are connected on a communication network 

(details will be described later) . A user logs in to this 
system as a requester or approver in accordance with the 
user (employee) ID from a predetermined Web page displayed 
on the client 1. When the user logs in as an approver, 

25 he/she can also use the article specifying function and 
approval request function. This arrangement allows 
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abolition of the conventional business procedures 
including preparation, issue, and transfer of physical 
purchase slips and office automation (OA) in purchasing 
various articles to be used in business offices. 
5 These functions are realized when the A/S 2 executes 

the module group of software constructing the system shown 
in Figs. 3 to 5 and stored in the A/S 2 in advance, and the 
client 1 executes the software shown in the flow chart of 
Fig. 3 0 as basic software for displaying windows (to be 

10 described later) shown in Figs. 9 to 29 on the display 22 
of the client 1. Each client 1 and A/S 2 communicate using 
the above-described intranet environment by the W/Ss 3. 

The purchase request system uses an automatic mail 
function provided by the above-described M/S 4 when the 

15 requester notifies the approver of an approval request 
(Fig. 7) or the approver notifies the requester of an 
approval result (Fig. 8) (details will be described later ) . 
<Software Executed in Client 1> 

Software executed in the client 1 will be described. 

20 Fig. 3 0 is a flow chart of software executed by each 

client in the purchase request system according to the 
embodiment of the present invention. In this case, a user 
logs in to the purchase request system as a requester. 

The storage unit 26 of the client 1 stores a browser 

25 program in advance, as described above. First, the user 
of the client 1, who will log in to the purchase request 
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system as a requester, starts the browser in accordance with 
a predetermined procedure so as to make the client of 
his/her own link to the purchase request system executed 
by the CPU of the A/S 2 (more specifically, the browser 
program in the storage unit 2 6 is loaded in the RAM 25, and 
the CPU 21 executes the loaded program) . Simultaneously, 
the user inputs predetermined URL to a predetermined area 
of the started browser. When the client is linked to the 
purchase request system through the W/S 3, the CPU 21 of 
the client 1 starts processing from step SI. 

In this embodiment, the program of the cross-check 
function from step S3 to step S5 is directly described in 
the file of a Web page described in the HTML as a tag of 
the JavaScript. The cross-check function can be executed 
by each client 1. When the A/S 2 executes the cross-check 
function, transmission of data input from keys and 
transmission of data representing that the transmitted data 
is inappropriate are necessary as communication between the 
client 1 and A/S 2. However, when the cross-check function 
is executed by the client 1 , the transmission can be omitted, 
and therefore, the waiting time of the user of the client 
1 can be made shorter than that when the A/S 2 executes the 
cross-check function . 

Since the program of the cross-check function is 
described as a tag of the JavaScript, every time a Web page 
described in the HTML is displayed, the client 1 can acquire 



the program of the cross-check function from the A/S 2 
together with data (to be referred to as display window data 
hereinafter) representing the layout of the displayed 
window. In addition, a program of old version can be 
5 prevented from remaining in the storage unit 2 6 of the 
client 1. This arrangement facilitates systematic 
management of the program of the cross-check function in 
the A/S 2 . 

Cg Step SI: The RAM 25 receives the display window data 

s"y' 10 of a home page (HP) and the like from the site (A/S 2) at 

f?j the link destination through the communication interface 

jr* 27 . In this embodiment, the general HTML (HyperText Markup 

" Language) is employed as the description language of a Web 

X 

\% page . 

^ 15 Step S2 : A window is displayed on the display 22 in 

\2 accordance with the display window data received from the 

A/S 2 and D/B 5 and data embedded in the display window. 

Step S3 : It is detected whether key input of a 
numerical value or the like from the keyboard 2 3 or pointing 
2 0 operation using the pointing device 2 8 is performed. 

Step S4 : If YES in step S3 (the input operation is 
detected) , it is determined whether a predetermined data 
input item is input in the window displayed on the display 
22 . If NO in step S4 (no predetermined data input item is 
25 input), the flow advances to step S7 . 

Step S5: If YES in step S4 (the predetermined data 
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input item is input) , it is determined whether the input 
data detected in step S3 satisfies a predetermined 
cross-check condition . If YES in step S5 , the flow advances 
to step S7 . 

5 Specific examples of the predetermined data input 

item and predetermined cross-check condition will be 
described later with reference to Figs. 20 and 21. 

Step S6 : If NO in step S5 (the condition is not 
satisfied) , a predetermined alarm message is displayed on 

10 the display 22 in accordance with the determination result 
(error) in step S5, and the flow returns to step S3. 

Step S7 : The input data detected in step S3 or data 
corresponding to the pointing operation is transmitted to 
the A/S 2 via the communication interface 27. 

15 Step S8 : It is determined whether a predetermined 

input operation for instructing to end the browser is 
performed. If NO in step S8 (no end instruction is input) , 
the flow returns to step S2 . If YES in step S8 (the end 
instruction is input) , the browser program is ended, and 

2 0 the area of the RAM 2 5 where the program has resided is 
released. 

In this embodiment, the program of the cross-check 
function is described as a tag of the JavaScript. If the 
system environment allows easy version management of 
25 programs stored in the storage unit 26 of each client 1, 
the program of the cross-check function which is compiled 
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■ " to the execution form in advance may be stored in the A/S 

2 . When a Web page described in the HTML is to be displayed 
on the client 1 for the first time, the program in the 
execution form may be downloaded to the client 1 in 
5 accordance with the tag of the Java applet contained in the 
file in advance. 
<Software Executed by A/S 2> 

Software executed by the CPU of the A/S 2 will be 
fl described next. First, the outline of the module group of 

Q 10 the software constructing the system shown in Figs. 3 to 

fs 5 will be described with reference to the flow charts shown 

in Figs . 31 and 3 2 . Next, window display processing common 
" to the modules will be described with reference to the flow 

Jj! chart shown in Fig. 32. Finally, the functions of the 

»» 15 modules shown in Figs. 3 to 5 will be described with 

*3 reference to windows shown in Figs. 9 to 2 9 (including 

Figs . 7 and' 8) . 

(1) Outline of Software Module Group of A/S 2 

Figs. 3 to 5 are views showing the system 
20 configuration of software executed by the A/S of the 

purchase request system according to the embodiment of the 
present invention. Fig. 6 is a view for explaining symbols 
used in Figs . 3 to 5 . 

The software module group (to be referred to as 
25 modules hereinafter) executed by the A/S 2 comprises eight 
modules of login (01), request state display processing 
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(02), purchase request processing (03), correction input 
processing (04), approval request processing (05), 
acceptance result display processing (06) , approval 
processing (07), and temporary worker management 
processing (08), as shown in Figs. 3 to 5 . These modules 
have a function of displaying various windows (to be 
described later) on the display 22 of the client 1 and 
realizing an input operation in the displayed window. 
Transition between the modules and window display in each 
module can be done as indicated by arrows and broken lines 
in Figs. 3 to 5 . 

A numeral (**-**-**) i n each block representing a top 
window or a window belonging to the top window is a window 
number. A top window is displayed first when the function 
to be used by the user of the client 1 is changed by a 
predetermined operation in the window (to be described 
later) . 

Figs. 31 and 32 are flow charts showing the outline 
of processing executed by the A/S of the purchase request 
system according to the embodiment of the present 
invention . 

Step Sll: It is determined whether the client 1 logs 
in through the W/S 3. The client 1 logs in from a 
predetermined HP displayed on the display 22 of the client, 
as described with reference to Fig. 30. 

Steps S12 and S13 : When a user ID ( including a password 
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from the second login) is received in step Sll, the 
personnel data 7 (including a password group registered in 
the D/B 5 from the second login) stored in the D/B 5 in 
advance is referred to (step S12) to determine whether the 
received user ID is an approver (step S13) . If YES in step 
S13 (the login user is an approver) , the flow advances to 
step S31 in Fig. 32. 

Step S14: If NO in step S13 (the login user is a 
requester), request state display processing (02) is 
performed. At this time, transition to correction input 
processing (04) is possible. 

Step S15: It is detected whether start request data 
for another module different from the module that is being 
currently executed is received from the login client 1 
through the W/S 3. If NO (the data is not received), the 
flow advances to step S21. 

Step S16: If YES in step S15 (the start request data 
is received) , processing of the module that is being 
executed is stopped. 

Steps S17 and S18: It is determined whether the start 
request data received in step S15 represents purchase 
request processing (step S17) . If YES in step S17 , purchase 
request processing is executed (step S18) . At this time, 
transition to approval request processing (05) is possible. 

Steps S19 and S20 : If NO in step S17 , it is determined 
whether the start request data received in step S15 



represents acceptance result display processing (stepS19) . 
If YES in step S19, acceptance result display processing 
is executed (step S20) . 

Step S21: It is detected whether data representing 
the end of use of this system is received from the login 
client 1 via the W/S 3. If NO in step S21 (the data is not 
received), the flow returns to step S15. 

Step S43: If YES in step S21 (the data representing 
the end of use is received) , processing of the module that 
is being executed is stopped. 

Step S31: When it is determined in step S13 that the 
login user is an approver, approval processing (07) is 
performed. 

Step S32: It is detected whether start request data 
for another module different from the module that is being 
currently executed is received from the login client 1 
through the W/S 3. If NO (the data is not received), the 
flow advances to step S42 . 

Step S33: If YES in step S32 (the start request data 
is received) , processing of the module that is being 
executed is stopped. 

Steps S34 and S35: It is determined whether the start 
request data received in step S32 represents request state 
display processing (02) (step S34). If YES in step S34, 
request state display processing (02) is executed (step 
S35) . At this time, transition to correction input 



* ~ processing (04) is possible. 

Steps S3 6 and S37: If NO in step S34, it is determined 
whether the start request data received in step S32 
represents purchase request processing (03) (step S36). 
5 If YES in step S36, purchase request processing (03) is 
executed (step S37) . At this time, transition to approval 
request processing (05) is possible. 

Steps S38 and S39 : If NO in step S36, it is determined 
rg whether the start request data received in step S32 

l'* 10 represents acceptance result display processing (06) (step 

S38) . If YES in step S38, acceptance result display 
^ processing (06) is executed (step S39). 

^ J Steps S40 and S41: If NO in step S38, it is determined 

\* whether the start request data received in step S32 

t-Li 

lU 15 represents temporary worker management processing (08) 

%5 (stepS40). If YES instep S40, temporary worker management 

processing (08) is executed (step S41) . On the other hand, 
if NO in step S40, the flow returns to step S32 . 

Step S42 : It is detected whether data representing 
20 the end of use of this system is received from the login 
client 1 via the W/S 3. If NO in step S42 (the data is not 
received), the flow returns to step S32. If YES in step 
S42 (the data representing the end of use is received) , the 
flow advances to step S43 . 
25 (2) Window Display Processing Common to Modules 

Fig. 3 3 is a flow chart showing window display 
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processing common to the modules executed by the A/S of the 
purchase request system according to the embodiment of the 
present invention. This processing is performed to 
display a window corresponding to the input operation by 
the user on the display 22 of the client 1 which is logging 
in the A/S 2. This processing is started by the CPU of the 
A/S 2 when the function to be used by the user of the client 
1 is changed by a predetermined operation in a window (to 
be described later) . 

Step S101: Data of each item necessary in the top 
window (i.e., top window corresponding to the function 
designated by a predetermined operation) to be displayed 
on the client 1 is read out from the D/B 5. 

In step S102 : The display window data of the top window 
to be displayed and the data read out from the D/B 5 in step 
S101 are transmitted to the login client 1 via the W/S 3 . 
Upon receiving the display window data and the like via the 
communication interface 27, the CPU 21 of the client 1 
interprets the received display window data by the browser 
function which is currently being executed and displays the 
top window on the display 22 in accordance with the 
interpretation . 

Step S103 : It is detected whether data representing 
the end of use of this system is received. If YES in step 
S103 (the data is received), processing is stopped. 

Step S104: If NO in step S103 (the data is not 




received) , it is determined whether data representing that 
a software button (to be referred to as a button 
hereinafter) (including an icon) is depressed (clicked) on 
the window currently displayed on the client 1 is received 
5 through the W/S 3. If NO in step S104 (the data is not 
received), the flow returns to step S103 . 

StepS105: If YES in step S103 (the data is received) , 
it is determined whether the button is a button for 
f ~ : selecting another function different from the function that 

5 \* 10 can be used by the user on the currently displayed window. 

~ y 

If YES in step S105 (another function button is clicked) , 
jH the flow returns to step S101. If NO in step S105 (another 

function button is not clicked) , the flow advances to step 
C3 S107. 

U 15 Step S106: If NO in step S103 (the data is not 

f ~: 

*1 received) , data received via the W/S 3 in accordance with 

the input operation by the user on the window which is 
currently being displayed on the client 1 is written 
(including update) in the D/B 5 and/or new data is read out 
20 from the D/B 5. 

Step S107 : The data read out in step S10 6 and display 
window data representing a window for displaying the data 
are transmitted to the login client 1 via the W/S 3 , as needed, 
and the flow returns to step S103 . Upon receiving the 
25 display window data and the like, as in step S102, the CPU 
21 of the client 1 displays a window belonging to the 
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currently displayed top window or a new window on part of 

the currently displayed window. 

(3) Description of Function of Each Window 

The detailed functions of the modules constructing 
5 the system shown in Figs. 3 to 5 will be described below 
with reference to main windows (Figs. 9 to 29) which can 
be displayed on the display 22 of the client 1. 
<Login (01) Module> 

Fig . 9 is a view showing a login window in the purchase 
10 request system according to the embodiment of the present 
invention . 

A login window 01-01-00 shown in Fig. 9 can be opened 
from a predetermined HP displayed on the client 1 by the 
above-described procedure (although details will be 

15 described later, the login window can be opened even by 
using the mailer function to be described later with 
reference to Figs. 7 and 8) . 

In this login window, the user inputs predetermined 
data in the columns of personal name (user ID) and password. 

20 When the "login" button is clicked, the input data are 
transmitted to the A/S 2 . The A/S 2 determines whether the 
user himself /herself logs in and whether the user is a 
requester or approver, on the basis of the user ID and 
password input as described above. In accordance with the 

25 determination result, the A/S 2 determines a top window 
which can transit to another window. When the "reset" 
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- * button is clicked, input to the columns of personal name 

and password can be reset (the "reset" buttons in other 
windows have the same function as described above, and a 
detailed description thereof will be omitted) . When "end" 
5 button is clicked, data representing the end of use of this 
system is transmitted to the A/S 2 (the "end" buttons in 
other windows have the same function as described above, 
and a detailed description thereof will be omitted) . When 
f3 the "user information register/change" button is clicked, 

10 the window shown in Fig. 10 is displayed. 
It Fig. 10 is a view showing the user information 

Y' t registration/change window in the purchase request system 

according to the embodiment of the present invention. 
^3 In a user information registration/change window 

iU 15 01-02-01 (when the user is a requester) shown in Fig. 10, 

E. '■ 

i5 a change in password, e-mail address, and extension number 

in the business office are input. The e-mail address is 
input to realize approval request notification from the 
requester to the approver (Fig. 7) and approval result 

20 notification from the approver to the requester (Fig. 8) 
(both will be described later) . The user who has completely 
input these items in this window clicks the 
"register /update" button (the "register /update" buttons in 
other windows have the same function as described above, 

25 and a detailed description thereof will be omitted) . The 
input data are transmitted to the A/S 2. When "return" 
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button is clicked, a window as an upper layer of the 
currently displayed window is displayed (the "return n 
buttons in other windows have the same function as described 
above, and a detailed description thereof will be omitted) . 
In this case, the login window 01-01-00 in Fig. 9 is 
displayed again. 

The dialogue box on the lower side of the broken line 
in the window shown in Fig. 10 is displayed to set a target 
approval section only when the login user is an approver. 
In this case, the window number is 01-02-02. In this 
dialogue box, the login user as an approver can change (add 
or delete) by himself /herself the sections (groups of 
requesters) in his/her charge in approving purchase 
requests. More specifically, to add a target section, the 
approver inputs the code of the section to the column of 
post code and clicks the "register" button. To delete a 
target section, he/she selects the section to be deleted 
from the list of current target sections and clicks the 
"delete" button. With this function, an approver can 
temporarily approve purchase requests from a section not 
in his/her charge by proxy for the original approver of the 
section due to some reason, so a more practical system can 
be realized. 

<Request State Display Processing Module (02) and 
Correction Input Processing Module (04)> 

Fig. 11 is a view showing a request state display 
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window in the purchase request system according to the 
embodiment of the present invention. This window is 
displayed first after login is complete when the user is 
a requester. Fig. 12 is a view showing the dialogue box 
for designating search conditions and display form in the 
request state display window. 

In a request state display window 02-01-01, the list 
of article purchase request statuses is displayed in 
accordance with conditions designated in the dialogue box 
for designating the search conditions and display form 
shown in Fig. 12 . The displayed data are data read out from 
the D/B 5. 

Buttons at the upper portion of the request state 
display window 02-01-01 shown in Fig. 11 will be described. 

On the " n articles selected" button, the number 
(number of types) of articles purchase-requested by the 
purchase request function realized by the purchase request 
processing module (03) ( to be described later ) is displayed. 
When this button is clicked, a requested article selection 
list window 03-03-00 shown in Fig. 17 is displayed to set 
the purchase quantity of the n articles. The "n articles 
selected" button may have a shape of, e.g., a shopping 
basket as shown in Fig. 13, on which the number of 
purchase-requested articles is displayed. 

When the "purchase request" button is clicked, a 
catalog search window 03-01-00 shown in Fig. 14, which is 



realized by the purchase request processing module (03), 
is displayed. 

When the "acceptance result" button is clicked, an 
acceptance result list window 06-01-00 shown in Fig. 23, 
which is realized by the acceptance result display 
processing (06), is displayed. 

When the " ? " button at the upper portion of the request 
state display window 02-01-01 is clicked, to display text 
data for explaining the function, which is stored in the 
D/B 5 in advance, a program for transmitting the data to 
the client 1 is executed by the A/S 2 (the " ? " buttons in 
other windows have the same function as described above, 
and a detailed description thereof will be omitted) . 

The plurality of buttons in the upper region of the 
above-described window or another window to be described 
below are actually displayed with any one of the buttons 
kept clicked in accordance with the displayed window. For 
the illustrative convenience, the button kept clicked in 
this region is indicated by a bold frame for discrimination 
from unclicked buttons. 

In the dialogue box for designating search conditions 
and display form shown in Fig. 12, search conditions and 
display form can be designated. 

As the search conditions to be designated, input of 
the section code of the request source or expense payer, 
the personal name code of the requester or approver, the 
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article request number, and the state of an article to be 
searched for (withdrawal, rejection, registration, and the 
like) can be designated. 

As the display form, the number of data to be displayed 
in one page can be designated in the column of list display 
count. In addition, a status window (request state display 
window 02-01-01 shown in Fig. 11) for mainly displaying the 
current status information of the individual articles or 
an expense window (window 02-01-02 which is not shown) for 
mainly displaying the expense information of individual 
articles can be selected. 

After the search conditions and display form are 
designated, the "search" button is clicked. With this 
operation, a request state display window according to the 
designated conditions is displayed on the display 22 of the 
client 1 . 

In the list of purchase request statuses of the 
request state display window 02-01-01 , the selection button, 
message, state (status) , request number, requester name, 
article name, request quantity, estimated amount, desired 
due date of delivery, due date of order, date of 
registration, date of request, date of approval, date of 
reception, date of order, date of delivery, date of 
acceptance, order quantity, delivery quantity, acceptance 
quantity, date of completion of order, delay answer (text) , 
and approver name can be displayed. This will be described 



below in more detail. 

Selection button: This button is clicked to select 
an article with a certain request number. 

Message : 0 is displayed in this column when a message 
for the requester or approver is present. 

State (status) : As the current state of an article 
with a certain request number, the A/S 2 selects one of 
"registered" , "wait for approval " , "approved" , "rejected" , 
and "withdrawn" (details will be described later) in 
accordance with operation in the window displayed by 
purchase request processing (03), approval request 
processing (05), and approval processing (07) (to be 
described later) . 

Request number: The reference number of an article 
in this purchase request system. The reference number is 
issued by the A/S 2. 

Requester name: The name of a requester who has 
requested to purchase an article with a certain request 
number. The name is selected from the personnel data 7 by 
the A/S 2 in accordance with the user ID. 

Article name: The name of a purchase-requested 
article. The article name is selected from the D/B 5 by 
the A/S 2 . 

Request quantity: The quantity of a 
purchase-requested article. This data is input by the 
requester . 



Estimated amount: The estimated price (or actual 
sales price) of a purchase-requested article. The amount 
is selected from the D/B 5 by the A/S 2. 

Desired due date of delivery: The date of delivery 
5 desired by the requester of a purchase-requested article. 
This data is input by the requester. 

Due date of order: The actually expected due date set 
in actual order by the procurement department. 

Date of registration: The date when the requester 
10 generates a purchase request and registers the data on the 
A/S 2 side for the first time. 

Date of request: The date when approval of a 
purchase-requested and registered article is requested. 
This date is registered by the A/S 2 in accordance with an 
15 operation in the window displayed by approval request 
processing (05) (to be described later). 

Date of approval : The date when an approval -requested 
article is approved by an approver . This date is registered 
by the A/S 2 in accordance with the operation of the approver 
20 in the window displayed by approval processing (07) (to be 
described later) . 

Date of reception: The date when a purchase-approved 
article is received by the procurement department. This 
date is reflected from the D/B 6 of the article ordering 
25 system to the D/B 5. 

Date of order: The date when the procurement 
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department has actually ordered an article for which 
reception is completed. This date is reflected from the 
D/B 6 of the article ordering system to the D/B 5. 

Date of delivery: The date when an article with a 
certain request number is delivered. This date is 
reflected from the D/B 6 of the article ordering system to 
the D/B 5. 

Date of acceptance: The date when a delivered article 
is accepted. This date is reflected from the D/B 6 of the 
article ordering system to the D/B 5. 

Order quantity: The quantity of articles actually 
ordered by the procurement department. This quantity is 
reflected from the D/B 6 of the article ordering system to 
the D/B 5. 

Delivery quantity: The delivery quantity of articles 
ordered by the procurement department. This quantity is 
reflected from the D/B 6 of the article ordering system to 
the D/B 5. 

Acceptance quantity: The acceptance quantity of 
articles delivered. This quantity is reflected from the 
D/B 6 of the article ordering system to the D/B 5 . 

Date of completion of order: The date when the order 
by the procurement department is completed. This date is 
reflected from the D/B 6 of the article ordering system to 
the D/B 5. 

Delay answer (text) : A comment associated with delay 




of the due date of delivery by the procurement department. 
This comment is input by a person in charge in the 
procurement department . 

Approver name: The name of an approver who has 
5 approved purchase of an article with a certain request 
number. The name is registered by the A/S 2 in accordance 
with an operation by the approver in the window displayed 
by approval processing (07) (to be described later). 

tj The statuses displayed in the column of state 

\~\ 10 (status) will be described. 

Sk "Registered": This status is set on the D/B 5 by the 

\* A/S 2 in the purchase request function realized by the 

— purchase request processing module (03) (to be described 

^ later) when the requester inputs a predetermined item about 

iU 15 a purchase-requested article and then performs a 

U registration operation. 

"Wait for approval": This status is set on the D/B 
5 by the A/S 2 in the approval request function realized 
by the approval request processing module (05) (to be 
20 described later) when an approval request for purchase is 
issued, and no determination is made yet by the approver. 

"Approved" : This status is set on the D/B 5 by the 
A/S 2 in the approval processing function realized by the 
approval processing module (07) (to be described later) 
25 when the approver approves purchase of an article in the 
"wait for approval" state. The state of the approved 
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article cannot be changed anymore. 

"Rejected" : This status is set on the D/B 5 by the 
A/S 2 in the approval processing function realized by the 
approval processing module (07) (to be described later) 
when the approver does not approve purchase of an article 
in the "wait for approval" state and rejects it. 

"Withdrawn" : This status is set on the D/B 5 by the 
A/S 2 when the requester withdraws the request in the 
request state display window 02-01-01 shown in Fig. 11 
before the approver determines approval or rejection of 
purchase of an article in the "wait for approval" state. 

The functions of buttons in the middle of the request 
state display window 02-01-01 shown in Fig. 11 will be 
described . 

When the "re-load" button is clicked, the request 
state list is re-displayed on the basis of the current data 
in the D/B 5 on the basis of designation of current search 
conditions and display form. 

After one or a plurality of articles are selected by 
clicking the column of selection (the same procedure as 
described above is used to select articles from another 
lists displayed on windows, and a detailed description 
thereof will be omitted) , the "requester change" button is 
clicked. With this operation a requester change window 
02-04-00 (not shown) in which the requester can be changed 
is displayed. 




When one or a plurality of articles are selected, and 
then, the "approval request" button is clicked, an approval 
request window 05-01-00 (05-02-00) for the selected 
articles is displayed. 
5 When one or a plurality of articles are selected, and 

the "correct" button is clicked, the input matters can be 
changed in windows 04-01-00, 04-02-00, and 04-03-00 (none 
are shown) displayed by the function of the correction input 
processing module (04). The correction input function 
10 realized by the correction input processing module (04) can 
transit to the approval request function realized by the 
approval request processing module (05). 

When one or a plurality of articles are selected, and 
the "withdraw" button is clicked, a withdrawal confirmation 
15 window 02-03-02 (not shown) is displayed. The requester 
can withdraw an article in the "wait for approval" state 
by inputting a predetermined operation in the displayed 
window . 

When one or a plurality of articles are selected, and 
20 the "delete" button is clicked, , a deletion confirmation 
window 02-03-01 (not shown) is displayed. When a 
predetermined operation is input in the displayed window, 
an article currently in the "withdrawn" or "registered" 
state can be deleted. 
2 5 When the A or ▼ mark is clicked in the purchase 

request status list, the display order of the list can be 
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rearranged in the ascending or descending order by a general 
method. 

The request state display module (02) can display a 
details confirmation window 02-02-00 (not shown) . In this 
5 window, detail information of a selected article can be 
confirmed . 

<Purchase Request Processing Module (03) and Approval 
Request Processing Module (05) > 

Fig. 14 is a view showing the catalog search window 
10 of the purchase request processing function of the purchase 
request system according to the embodiment of the present 
invention . 

In a catalog search window 03-01-00, the requester 
selects an article for which purchase is to be requested 

15 from catalog data stored in the D/B 5 in advance. In the 
catalog data, data such as the article name, type, maker, 
estimated amount (estimated purchase amount) , and normal 
due date of delivery are registered and managed in units 
of articles by, e.g., the person in charge in the 

2 0 procurement department. 

An article can be selected by keyword search or genre 
search . 

In keyword search, a keyword or a chemical substance 
registration number is input, and the number of search 
25 results to be displayed in one page is set in the display 
count input column. When the "search" button is clicked, 



- 38 - 




a catalog list window 03-02-00 according to the designated 
conditions is displayed on the display 22 of the client 1. 

Fig. 15 is a view showing the catalog list window of 
the purchase request processing function of the purchase 
5 request system according to the embodiment of the present 
invention . 

In the catalog list window 03-02-00 shown in Fig. 15, 
the data of articles selected from the catalog data in the 
fl D/B 5 on the basis of the designated search conditions are 

[ L i 10 displayed in a number corresponding to the display count 

tf\ designated in the catalog search window 03—01—00 . When an 

article name is clicked, an article description window 
l~ 03-04-02 (not shown) in which the description of the article 

is made is displayed. 
^ 15 The catalog list window 03-02-00 has the "many-item 

%3 request" button and "one- item request" button. 

a. ; 
ss 

More specifically, after one or more desired articles 
are clicked in the selection column of the catalog list 
window 03-02-00 , the "many-item request" button is clicked . 

20 With this operation, the number of types clicked is added 
to the " n articles selected" . When the user clicks the 
"n articles selected" button, a requested article selection 
list window 03-03-00 shown in Fig. 17 is displayed. 

When only one desired article is clicked in the 

25 selection column of the catalog list window 03-02-00, and 
then, the "one-item request" button is clicked, a detail 
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information input window 03-06-00 for a one-item request 
shown in Fig. 2 0 is displayed. 

The windows to be opened will be described later in 
detail. In "many-item request" , a plurality of types of 
articles desired are selected from the plurality of 
articles displayed in the catalog list window 03-02-00, and 
approval requests for purchase of the selected plurality 
of articles are issued. In "one-item request", only one 
desired article is selected from the plurality of articles 
displayed in the catalog list window 03-02-00, and an 
approval request for purchase of the selected article is 
issued . 

In genre search, from a pull-down menu displayed by 
clicking the "open" button (Fig. 14) , item groups to which 
the desired article belongs are selected one by one in the 
order of genre 1 — * genre 2 — > genre 3. When the "list 
display" button is clicked, a list of articles (catalog list 
window 03-02-00) corresponding to the item group selected 
in the genre is displayed. 

When the "repeat" button (Fig. 14) is clicked, of 
articles which belong to the item group selected in genre 
1 and are accepted by the previous month, articles for which 
purchase requests are issued by "individual request" are 
displayed as a list in a repeat search window 03-08-00 (not 
shown) . This window can conveniently transit to an 
individual input window 03-07-00 shown in Fig. 16 when the 
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desired article is not present in the displayed list. 

The "individual request" button (Fig. 14) is used 
when the desired article cannot be found from the catalog 
data in the D/B 5 by the above-described keyword search, 
5 genre search, and "repeat" function. When this button is 
clicked, the individual input window 03-07-00 shown in 
Fig. 16 is displayed. 

Fig. 16 is a view showing the individual input window 
li of the purchase request processing function of the purchase 

|j 10 request system according to the embodiment of the present 

r n 

ff: invention. When purchase of an article unregistered on the 

catalog data in the D/B 5 is to be requested, detail 

a. y 

information of the desired article can be input. 
It In the individual input window 03— 0V— 00 shown in 

l y 

15 Fig. 16, necessary matters are input to the columns of the 

tL y 

W window. When a plurality of requesters are requesting 

purchase of an article unregistered in the catalog data, 
input data about the same article are transmitted from the 
plurality of requesters to the A/S 2 . The person in charge 
20 in the procurement department can easily recognize the 
necessity of the article on. the basis of the number of input 
data about the same article. For this reason, the scale 
of buy in a mass (lot) for the next delivery and the unit 
price (expected unit price) for the buy in a mass can be 
25 accurately predicted. 

When the necessary matters are completely input in 
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the individual input window, and the "next" button is 
clicked, an article information (detail input) window 
03-06-00 shown in Fig. 20 is displayed. When the "select" 
button is clicked, the request is added as one of the 
5 plurality of requests, so the value n on the "n articles 
selected " button is incremented by one. When the "n 
articles selected" button is clicked, the requested article 
selection list window 03-03-00 shown in Fig. 17 is 
displayed to set the purchase quantity of the n articles, 

10 as described above. 

Fig. 17 is a view showing the requested article 
selection list window of the purchase request processing 
function of the purchase request system according to the 
embodiment of the present invention. 

15 The requested article selection list window 03-03-00 

shown in Fig. 17 shows a case wherein three articles are 
selected in the catalog list window 03-02-00 . The purchase 
quantity of each of the selected articles can be input to 
the column of requested quantity. 

20 The requested article selection list window 03-03-00 

has the "many-item details input" button and "one-item 
details input" button. 

More specifically, when two or more desired articles 
are clicked in the column of selection of the requested 

25 article selection list window 03-03-00, and the "many-item 
details input" button is clicked, a detail information 
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input window 03-05-00 for a many-item request shown in 
Fig. 18 is displayed. 

When only one desired article is clicked in the column 
of selection of the requested article selection list window 
5 03-03-00, and the "one-item details input" button is 

clicked, a detail information input window 03-06-00 for a 
one-item request shown in Fig. 20 is displayed. 

Fig. 18 is a view showing the detail information 
input window for a many-item request of the purchase request 
10 processing function of the purchase request system 

according to the embodiment of the present invention. 

In the detail information input window 03-05-00 shown 
in Fig. 18, pieces of information including the expense 
payer, section code, accounts (account title) , expense, 
15 facility budget code, desired due date of delivery, and 
delivery business office are input in association with 
purchase of the plurality of articles selected in the 
requested article selection list window 03-03-00. 
When the "account list" button is clicked, 
20 combinations of selectable account titles and expenses are 
displayed as a list. 

In this embodiment, in inputting these items in this 
window (including the detail information input window 
03-06-00 shown in Fig. 20) , the cross-check function 
25 described above with reference to Fig. 30 is executed by 
the CPU 21 of the client 1 to check the suitability of the 
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format of input data to a predetermined item. 

Fig. 21 is a view showing conditions of cross-check 
executed by the client in inputting data to the detail 
information input window in the purchase request system 
5 according to the embodiment of the present invention. 

In the list of cross-check conditions shown in 
Fig. 21, conditions of an input format (e.g. , the character 
string and/or numerical string to be used) to be satisfied 
by input data of a predetermined item such as the expense 

10 or facility budget code are determined on the basis of data 
input to the column of account (account title) of the detail 
information input window 03-05-00 as a key. The data of 
cross-check conditions are stored in the D/B 5 in advance. 
These data are stored in the RAM 2 5 of the client 1 when 

15 the display window data of an HP or the like is received 
in step SI of Fig. 30. 

When input to the plurality of items of the detail 
information input window 03-05-00 is ended, and the 
requester clicks the "register" button, the data input at 

20 this time point is transmitted to the A/S 2. 

Upon receiving the data of detail information, the 
A/S 2 compares the data of date input to the column of desired 
due date of delivery of the detail information input window 
with the calendar data for the company (business office) , 

25 which is registered in the D/B 5 in advance, thereby 

determining whether the desired due date of delivery is the 
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date of a holiday in the calendar data. 

If it is determined that the desired due date of 
delivery is not the date of a holiday in the calendar data, 
the A/S 2 writes the data of detail information in the D/B 
5. 

If the desired due date of delivery is the date of 
a holiday in the calendar data, the A/S 2 transmits 
predetermined display window data to the client 1 that has 
transmitted the data of detail information to display an 
error window 03-11-01 shown in Fig. 22. 

Fig. 22 is a view showing the error window displayed 
when the desired due date of delivery input in the detail 
information input window has an error in the purchase 
request system according to the embodiment of the present 
invention . 

In the error window 03-11-01 shown in Fig. 22, a 
predetermined error message representing that the desired 
due date of delivery input by the requester in the detail 
information input window 03-05-00 is the date of a holiday 
in the calendar is displayed. In addition, the "OK" button 
and "ignore" button are displayed. 

When the "OK" button is clicked, the detail 
information input window 03-05-00 is displayed again to 
newly set the desired due date of delivery. When the 
"ignore" button is clicked, predetermined data 
representing that the requester desires delivery of the 



article at the desired due date of delivery, though he/she 
agrees that the desired due date of delivery currently set 
is the date of a holiday, is transmitted to the A/S 2 . Upon 
receiving the predetermined data, the A/S 2 writes the data 
5 of detail information in the D/B 5. 

When the "approval request" button is clicked in 
association with the article whose detail information is 
written in the D/B 5 (i.e., the article registered in the 
p detail information input window 03-05-00) , an approval 

Q 10 request window 05-01-00 for a many- item request shown in 

£0 

f? : Fig. 19, which can be displayed by the approval request 

% : ; 

s : 
5 = = 

n processing module (05), is displayed. 

%d The function of confirming the desired due date of 

f ~ 

delivery is also executed for the detail information input 
15 window 03-06-00 for a one-item request. 
%2 Fig . 19 is a view showing a state wherein the approval 

request window for a many-item request is displayed 
together with the detail information input window by the 
approval request processing function of the purchase 
20 request system according to the embodiment of the present 
invention . 

In the approval request window 05-01-00 for a 
many-item request shown in Fig. 19, approvers in charge for 
the section to which the requester who is requesting 
25 approval belongs are displayed by a pull-down menu (when 
proxy approvers are set in the login window 01-02-02, the 
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proxy approvers are displayed) . The requester selects one 
of the approvers from the menu and clicks the "OK" button. 
With this operation, the purchase request operation and 
approval request operation for a plurality of articles by 
the requester are ended. At this time point, mail (Fig. 7) 
for notifying the approver of the approval request is 
transmitted to the approver selected in the menu by the 
mailer function of the M/S 4. 

Fig . 20 is a view showing a state wherein the approval 
request window for a one-item request is displayed together 
with the detail information input window by the approval 
request processing function of the purchase request system 
according to the embodiment of the present invention. 

Referring to Fig. 20, the detail information input 
window 03-06-00 for a one- item request and the approval 
request window 05-02-00 for a one-item request are 
displayed together. Catalog data of an article selected 
in the requested article selection list window 03-03-00 is 
displayed as "article information" at the left portion of 
the detail information input window. As in the approval 
request window 05-01-00 shown in Fig. 19, the requester 
requests the approver for approval in the approval request 
window 05-02-00. For a one-item request as well, mail for 
notifying the approver of the approval request is 
transmitted to the approver selected in the menu at this 
time point. 



<Acceptance Result Display Processing Module (06) > 

Fig. 23 is a view showing the acceptance result list 
window displayed by the acceptance result display function 
in the purchase request system according to the embodiment 
of the present invention. 

In an acceptance result list window 06-01-00 shown 
in Fig. 23, an operation method designation dialogue box 
is displayed, like the dialogue box for designating search 
conditions and display form in the request state display 
window 02-01-01 shown in Fig. 12. When predetermined 
items are input to this designation dialogue box, and the 
"search" button is clicked, accepted articles readout from 
the D/B 5 are displayed as a list. 

The functions that can be executed by the user of the 
client 1 as the requester from the display 22 have been 
described above. 

Next, various functions that can be executed by the 
user of the client 1 as an approver will be described. The 
approver can use the above-described functions as a 
requester and also use the approval processing function 
realized by the approval processing module (07) , which can 
be executed by only the approver, and the temporary worker 
management function realized by the temporary worker 
management module (08). In the following description, a 
detailed description of functions that can be used by the 
approver as a requester will be omitted, and the approval 
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processing function (07) and temporary worker management 
function (08) will be described. 

In accessing the purchase request system, the 
approver can log in to the system from the above-described 
5 predetermined HP. When approval request mail is received, 
the approver can also access the system from a mailer window 
shown in Fig . 7 . The procedure of access will be described . 

Fig. 7 is a view showing a mailer window displayed 
when approval request mail is sent to the approver by the 

10 mailer function of the purchase request system according 
to the embodiment of the present invention. 

Approval request mail from the requester is 
transmitted by the M/S 4 to the approver designated by the 
requester, and a window 31 shown in Fig. 7 is displayed on 

15 the client 1 of the approver. When the approver clicks an 
approval request number column 32, the mail addresses of 
the requester and approver, a comment representing that an 
approval request is received, and the URL of the purchase 
request system are displayed at the lower portion of the 

20 window 31. When the approver clicks the URL portion of a 
display area 33, the above-described login window 01-01-00 
shown in Fig. 9 is displayed. The approver can log in to 
the purchase request system from this window. 

The reason why the system is set such that the login 

25 window can be opened from the mailer window is as follows. 
The login window has a relatively small number of displayed 
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items and a large blank portion. When the system manager 
describes information items using the blank portion, the 
approver can easily recognize the message of the 
information items on the layout. 
5 However, the window to be opened is not limited to 

this. For example, when priority is given to the 
convenience for the approver, the mail address of the 
approver, which is set as the destination of the mail, is 
acquired from the M/S 4 to the A/S 2. The user ID of the 

10 approver is read out from the D/B 5 to the A/S 2 on the basis 
of the mail address. Processing from login to opening of 
an approval request list window 07-01-00 can be 
automatically performed by the A/S 2 using the readout user 
ID. In this case, since the approver need not perform the 

15 login operation by himself /herself , the convenience for the 
approver can be improved. 
<Approval Processing Module (07)> 

When login of the approver from the login window 
01-01-00 is ended, the approval request list window 

20 07-01-00 shown in Fig. 24 is displayed on the display 22 
of the client 1 of the approver by the function of the 
approval processing module (07), as described above with 
reference to Figs. 31 and 32. 

Fig. 24 is a view showing the approval request list 

2 5 window displayed by the approval processing function in the 
purchase request system according to the embodiment of the 



- 50 - 



present invention . 

Not only buttons representing functions that can be 
used by a requester but also the "approval processing" 
button and "temporary worker management" button are 
5 provided at the upper portion of the approval request list 
window 07-01-00 shown in Fig. 24. 

In the approval request list window, various data of 
an article for which approval request mail is received are 
displayed as a list, as shown in Fig. 24. Even when one 

10 approval request number is clicked in the window 31 shown 
in Fig. 7, all articles read out from the D/B 5 by the A/S 
2 on the basis of the user ID of the approver are displayed 
as a list on the approval request window. 

When a request number in the list displayed in the 

15 window is clicked, a details confirmation window (not 

shown) in which detail information of the article with the 
request number is displayed. The window has the "approval 
select" button and "rejection select" button. The 
functions of these buttons will be described below. 

20 Fig. 2 5 is a view showing the approval processing 

window of the approval processing function in the purchase 
request system according to the embodiment of the present 
invention . 

A approval processing window 07-02-01 shown in 
25 Fig. 2 5 is displayed at the lower portion of the approval 
request list window or as another window when one or more 
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articles are selected in the approval request list window 
07-01-00, and the "approval select" button is clicked. 
When an amount more than ¥200,000 is set for an article to 
be approved, a predetermined message representing this 
amount is displayed, as shown in Fig, 25. This aims at 
calling the approver's attention to confirm whether the 
purchase quantity of the article has no input error. When 
the "OK" button is clicked in this approval processing 
window 07-02-01, purchase of the article displayed in this 
window is approved. Predetermined data representing 
approval is transmitted to the A/S 2, and the status of the 
article in the D/B 5 is updated from "wait for approval" 
to "approved" . 

When the status of the article in the D/B 5 is updated 
to "approved" , the column of the approved article is deleted 
from the displayed items of the list of the approval request 
list window 07-01-00 (In the display example in Fig. 24, 
one article is displayed as an approval-requested article. 
In this case, only predetermined items of the list are 
displayed by "approving" the article) . 

Fig. 26 is a view showing the rejection processing 
window of the approval processing function in the purchase 
request system according to the embodiment of the present 
invention . 

A rejection processing window 07-02-02 shown in 
Fig. 26 is displayed at the lower portion of the approval 




request list window or as another window when one or more 
articles are selected in the approval request list window 
07-01-00, and the "rejection select" button is clicked. 
When the "OK" button is clicked in this re j ection processing 
5 window 07-02-02, purchase of the article displayed in this 
window is rejected. Predetermined data representing 
rejection is transmitted to the A/S 2, and the status of 
the article in the D/B 5 is updated from "wait for approval" 
to "rejected" . 

10 When the approver performs the approval or rejection 

operation as described above, data in the D/B 5 is updated. 
In addition, mail for notifying the requester that the 
purchase of the approval-requested article is approved or 
rejected is transmitted to the requester by the automatic 

15 mail function of the M/S 4. 

Fig. 8 is a view showing a mailer window displayed 
when mail replying to the approval request is sent to the 
requester by the mailer function of the purchase request 
system according to the embodiment of the present 

2 0 invention. 

Mail from the approver is automatically transmitted 
by the M/S 4 to the mail address which is registered in 
advance by the requester of the article for which approval 
or rejection is determined. Thereby, a window 31 shown in 

25 Fig. 8 is displayed on the client 1 of the requester. When 
the requester clicks an approval request number column 34, 
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the mail addresses of the requester and approver, a comment 
representing that the reply to the approval request is 
received, and the URL of the purchase request system are 
displayed at the lower portion of the window 31. When the 
requester clicks the URL portion of a display area 35, the 
above-described login window 01-01-00 shown in Fig. 9 is 
displayed. The requester can log in to the purchase request 
system from this window and confirm the latest state of the 
requested article in the request state display window 
02-01-01. 

In this case as well, as in the mail window shown in 
Fig. 7, when the mail address of the requester, which is 
set as the destination of the mail, is acquired from the 
M/S 4 to the A/S 2. The user ID of the requester is read 
out from the D/B 5 to the A/S 2 by looking up the D/B 5 on 
the basis of the mail address. When processing from login 
to opening of the request state display window 02-01-01 is 
automatically performed by the A/S 2 using the readout user 
ID, the requester need not perform the login operation by 
himself /herself , the convenience for the requester can be 
improved . 

<Temporary Worker Management Processing Module (08)> 

When the "temporary worker management" button is 
clicked by the approver, a temporary worker list window 
08-01-00 shown in Fig. 27 is displayed by the function of 
the temporary worker management processing module (08) . 



Fig. 27 is a view showing the temporary worker list 
window of the temporary worker management function in the 
purchase request system according to the embodiment of the 
present invention . 

In the temporary worker list window 08-01-00 shown 
in Fig. 27 , a temporary worker (the user of the client 1 
who is not registered in the personnel data 7) can be 
registered, corrected, or deleted as a requester of this 
system. At this time, on the basis of the user ID (employee 
code) of the login user as an approver, data of temporary 
workers registered by the section code of the section 
managed by the user are read out from the D/B 5, and the 
temporary workers are displayed on the client 1 of the 
approver as a list in the window. 

To register a temporary worker , the "register" button 
of the temporary worker list window 08-01-00 is clicked. 
A temporary worker registration window 08-02-01 shown in 
Fig. 28 is displayed at the lower portion of the temporary 
worker list window or as another window. 

Fig. 2 8 is a view showing the temporary worker 
registration window of the temporary worker management 
function in the purchase request system according to the 
embodiment of the present invention. 

In the temporary worker registration window 08-02-01 
shown in Fig. 28, predetermined items such as the name, date 
of birth, staffing agency, and business office of a 




temporary worker to be registered are input, and then, the 
"OK" button is clicked. The input data are transmitted to 
the A/S 2 and written in the D/B 5. 

To delete a temporary worker, the target temporary 
5 worker is selected from the list in the temporary worker 
list window 08-01-00, and the "delete" button is clicked. 
With this operation, a temporary worker deletion window 
08-02-03 shown in Fig. 29 is displayed at the lower portion 
of the temporary worker list window or as another window. 

10 Fig. 2 9 is a view showing the temporary worker 

deletion window of the temporary worker management function 
in the purchase request system according to the embodiment 
of the present invention. 

In the temporary worker deletion window 08-02-03 

15 shown in Fig. 29, the registered information of the 

selected temporary worker is displayed. When the "OK" 
button in this window is clicked, predetermined data 
representing deletion is transmitted to the A/S 2. The 
registered data of the temporary worker is deleted from the 

20 D/B 5. 

To correct the registered data of a temporary worker , 
the "correct" button is clicked in accordance with the same 
procedure as that for deletion. A temporary worker 
correction window 08-02-02 (not shown) substantially the 
25 same as for deletion in Fig. 29 is displayed. Data is 
corrected in this window, and the "OK" button is clicked. 
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According to the temporary worker management 
function realized by the above-described temporary worker 
management processing module (08) , temporary workers which 
are not registered in the personnel data 7 can be 
appropriately managed. 
[ Other Embodiments ] 

The object of the present invention can be achieved 
even by supplying a storage medium storing software program 
codes for realizing the function of the above-described 
embodiment to a client and server, and causing the computer 
(or a CPU or an MPU) of the client or server to read out and 
execute the program codes stored in the storage medium. 

In this case, the program codes read out from the 
storage medium realize the function of the above-described 
embodiment by themselves, and the storage medium storing the 
program codes constitutes the present invention. 

As a storage medium for supplying the program codes, 
a floppy disk, a hard disk, an optical disk, a magnetooptical 
disk, a CD-ROM, a CD-R, a magnetic tape, a nonvolatile memory 
card, a ROM, or the like can be used. 

The function of the above-described embodiment is 
realized not only when the readout program codes are executed 
by the computer but also when the OS (Operating System) 
running on the computer performs part or all of actual 
processing on the basis of the instructions of the program 
codes . 



The function of the above-described embodiment is also 
realized when the program codes read out from the storage 
medium are written in the memory of a function expansion board 
inserted into the computer or a function expansion unit 
connected to the computer, and the CPU of the function 
expansion board or function expansion unit performs part or 
all of actual processing on the basis of the instructions 
of the program codes. 

As has been described above, according to the above 
embodiment, the conventional business procedures including 
preparation, issue, and transfer of physical purchase slips 
are abolished, and the following matters are realized. 

According to the client 1 (client 1 used by the user 
as a requester) as the purchase request apparatus in the 
above-described purchase request system, purchase of 
various articles can be efficiently requested. 

According to the client 1 (client 1 used by the user 
as a requester) as the purchase request apparatus in the 
above-described purchase request system, purchase requests 
of various articles and change in requested contents become 
flexible . 

According to the client 1 (client 1 used by the user 
as a requester) as the purchase request apparatus in the 
above-described purchase request system, data associated 
with a desired article to be purchase-requested can be 
accurately input. 




According to the above-described purchase request 
system, various articles can be efficiently purchased using 
the existing terminal group. 

According to the above-described purchase request 
5 system, various articles can be efficiently purchased. In 
addition, according to the above-described purchase 
request system, temporary workers which are not registered 
in the personnel database can be appropriately managed. 

According to the client 1 (client 1 used by the user 
10 as an approver) as the purchase request approving apparatus 
in the above-described purchase request system, approval 
or rejection of a purchase-requested article can be 
efficiently input . 

As many apparently widely different embodiments of the 
15 present invention can be made without departing from the 
spirit and scope thereof, it is to be understood that the 
invention is not limited to the specific embodiments thereof 
except as defined in the appended claims. 
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